IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and IMS Application Servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber that the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, IMS Application Servers (ASs) are provided for implementing IMS service functionality. IMS Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a subscriber's Subscriber Profile.
An example IMS service that is facilitated by the use of ASs is that of Multimedia Telephony (MMTel). MMTel allows a single SIP session to control virtually all MMTel supplementary services and MMTel media. All available media components can be easily accessed or activated within the session. Employing a single session for all media parts means that no additional sessions need to be set up to activate video, to add new users, or to start transferring a file.
The provision of new IMS-based services by network operators and third party service providers has conventionally required a detailed technical knowledge of SIP and IMS protocols and network architectures. In order to simplify this process, and therefore increase the range of IMS services and the speed with which they can be introduced, the Third Generation Partnership Project (commonly known as 3GPP) has been working on a so-called Open Service Access (OSA) architecture. The object of the OSA work has been to provide a set of (sometimes freely available) Application Programming Interfaces (APIs) that will allow systems developer that are unfamiliar with the IMS/SIP architecture and standards to develop applications that can make use of the IMS network and its services. These APIs can be considered relatively high level abstractions of the underlying mechanisms and as such should be simple to use. The APIs are often referred to as “handlers”.
To date, 3GPP has described a number of such APIs (currently 22). These are specified in 3GPP TS 29.199-3 V8.2.0 and all are based on Parlay X. Parlay X is a set of Web service APIs specified by a group including 3GPP and ETSI. The OSA APIs can be used in interactions between an IMS Application Server and a “north bound” value added service server (hereafter referred to as ‘VAS’). The OSA APIs are intended to be powerful but nonetheless easy to use. A designer of a VAS service does not have to learn the details of SIP or IMS to be able to design services for such environments.
By way of example, the OSA architecture may be used to implement a “click to call” service, whereby a user initiates a call between himself/herself and a third party by clicking a link on a web page. The request is routed, via the Internet, to the VAS which instructs an MMTel AS, using the appropriate OSA API (e.g. “MakeCallSession”, with the addresses of the peer users as argument) to set up the call between the parties. In practice, the MMTel AS will send a SIP INVITE to the initiator's IMS enabled terminal. When the user answers the call, connection to the peer user is initiated over the IMS network.
The ‘CallNotification’ API (TS 29.199-3) describes in ‘CallNotificationManager’ a subscription handler to be used between an IMS system and the VAS. Such a subscription may be used, for example, to alert the VAS of incoming calls directed to a particular user, where the VAS determines a call handling procedure on behalf of the MMTel. The VAS starts a subscription by sending a ‘StartCallNotificationRequest’ handler. This API contains a unique reference for the subscription and may include several user addresses (typically URIs) in one request. The AS handling the subscription acknowledges the request to the VAS, providing the VAS with a “correlator” identifying the particular subscription. When an event occurs in the IMS that matches the subscription, an appropriate notification is sent over Parlay X to the VAS. The VAS may then act on the notification and send action instructions to the IMS. The subscription is ended by sending a ‘StopCallNotificationRequest’ from VAS to IMS, the message including as argument the appropriate correlator.
One of the problems with the currently described functionality in OSA subscription handling is the way a subscription is stopped. The stop handler only contains the unique ‘correlator’ that is created at the start of the subscription. Since OSA subscriptions are not refreshed, one can assume that a subscription is started at provisioning time of users in VAS, i.e. all users provisioned within a certain time frame (e.g. each day) are sent in one subscription. [The only thing in common for these users may be the time of provisioning.]
A subscription should act as a ‘trigger’ in the AS for a user with an active OSA subscription. Therefore, the subscription must be tied to the user data in the AS. The AS needs functionality to step through the users in the subscription and update user data for these users. The AS must also save the pointer between the unique correlator for the subscription and the users that the correlator it is applicable to. When, later, a ‘StopCallNotificationRequest’ is received with only the correlator as argument, the AS must find the pointer to which users it is applicable and update user data. This subscription termination process is illustrated in FIG. 2, for a subscription made in respect of a set of three users. A function is provided within the IMS to perform a mapping between correlators and respective sets of user addresses
Since in general it will be only a common subscription time that ties a group of users together, it is difficult to envisage an event that should trigger a de-subscription of the same group of users. Therefore, in order to allow de-subscribe of individual users, it is likely that real-world implementations of the proposed OSA architecture will include within a ‘StartCallNotificationRequest’ message only a single subscriber address, rather than a set of such addresses. Nonetheless, such implementations will still require within the IMS, functionality to point from a correlator (included in the StopCallNotificationRequest) to a user. This approach is inefficient not least because it requires one subscription message to be sent from the VAS to an AS for each and every subscriber.
Whilst the OSA architecture has to date specified only Parlay X based APIs, it is likely that in the future further handlers will be specified using other Web service interfaces. Examples of alternative possible Web service interfaces include those based upon Representational State Transfer (REST) and OneAPI. However, without adaptation of the core OSA principles, handlers using such alternative Web service interfaces would suffer from the problems discussed above.